Subject: Re: The problem of the framework draft

From: HJ Sandick <[email-masked]>
Date: Mon, 5 Jan 1998 17:24:25 -0500

Ohta-san,

I agreed with Eric and Brian Card.  Inter and intra domain routing is the way
that the internet is configured today.  When we wrote the framework draft we
felt that the most realistic deployment scenario for QOS routing was
incremental changes to the existing routing protocols and routing
infrastructure.    The reason we haven't specified the interface between inter
and intra domain routing is because this is a framework document and not a
protocol specification.

Regards,

Hal

Hal Sandick
IBM, NHD
(919) 254-4614
sandickh@ibmusm20 (internal ibm)
[email-masked] (external)

[email-masked] on 01/01/98 09:15:12 AM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet
cc: [email-masked] @ internet, [email-masked] @
internet
Subject: The problem of the framework draft

Eric;

> There are more but I think I have belabored the point enough.  You can
> disagree that there are better technical approaches than Inter/Intra domain
> but the reality is that the current Internet is configured this way and no
> solution or approach can ignore it.

The basic problems of the current framework draft are that:

 The draft says some QoSR protocols have problems, which
 does not mean all the QoSR protocols have the same
 problems.

 The draft says some QoSR protocols have problems, and
 expect that some inter-domain QoSR can magically solves
 the problem.

 The draft does not show inter/intra domain separation
 possible.

 The draft does not specify the interface (if any, at all)
 between inter/intra domain QoSR, which makes many
 (if not all) intra domain QoSR can not interoperate
 with inter domain QoSR.

 The draft debates that the introduction of routing hierarchy is
 necessary and wrongly concludes that inter/intra domain
 separation necessary.

Any counter arguments?

      Masataka Ohta

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 06 Jan 1998 09:19:10 +0000

In message <5040100013058692000002L022*@MHS>, HJ Sandick typed:

 Hal

a very good reason for making this distinction is that it is likely
that the mechanmisms for billing for QoS will be quite different intra
and inter-domain - for example, it may be that settlements suffice for
inter-domain, while per session billing is needed for diff and
int-serv intra domain in the "home" and "away" ISPs....- the
facilities could probably be added to inter-domain routing protocols
to carry relevent info for settlements (provided sufficient traffic
omoniroting, which is pretty normal in internet exchanges) right now,
whereas for per session billing, a lot more work is needed (e.g.
brokers etc etc...) so i think this is just one more reason to make
the distinction....

its not elegant, but its pragmatic....

regards
 >>IBM, NHD

 cheers

   jon

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 06 Jan 1998 09:19:10 +0000

Hal

regards

 cheers

   jon

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 6 Jan 98 18:21:04 JST

Hal;

There is no inter or intra domain RSVP. Right?

RSVP works beyond domain boundaries but can be deployed
incrementally. Right?

> infrastructure.

That there is some boundary today means that some protocols *MAY*
follow the boundary.

It does NOT mean protocols *MUST* follow the boundary.

Worse, it does NOT mean new protocols *CAN* follow the boundary.

We don't need intra domain RSVP specificaiton confined in a
single domain.

As I already wrote in the previous mail, QoS routing protocols
with no inter/intra domain separation can be deployed a lot
more incrementally than those with the separation.

> The reason we haven't specified the interface between inter

That's not a problem.

The problem is that the interface may not exist.

For the framework document require the separation, it should
provide the existence proof of the interface.

The easist way to do so is to show the framework of the interface.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 6 Jan 98 18:50:27 JST

Jon;

> brokers etc etc...) so i think this is just one more reason to make

As you know, RSVP policy payload may be different location by location,
which does not make it necessary to have ST2 for intra-domain and RSVP
inter-domain and to pray them interoperate.

> its not elegant, but its pragmatic....

Policy is policy, protocol is protocol.

							Masataka Ohta

---

From: "Eric S. Crawley" <[email-masked]>
Date: Sun, 11 Jan 1998 10:46:30 -0500

[My apologies for taking so long to respond to this series of messages.  My
day job has been getting in the way ;)]

Ohta-san,

I believe that the recent exchange of messages has clarified a number of
issues regarding your approach to QoSR.  Let me see if I can outline a way
forward that will address at least some of your issues:

- Any good framework document needs to mention the current approaches to
the problem the framework is addressing.  Now that we have a better
understanding of your approach, we should be able to discuss it in the
framework.  I am going to propose to my co-authors that we mention and
reference your approach in sections 3.4 and 7 along with possible mention
in section 3.5.

- We have some confusion in the document about AS boundaries and routing
protocol boundaries.  Any QoSR work, including your approach, will require
modification to routing protocols.  We need to be specific that the
framework is encouraging these modifications starting with intradomain
routing protocols and moving to interdomain protocols.  This is a pragmatic
approach based on the current set of routing protocols and their respective
deployment.  We will want to encourage common, or at least easily
translatable, metrics so QOSR interfaces between the routing protocols will
be easier.

- I believe there are three forms of aggregation that need to be discussed:
metric aggregation, route aggregation, and flow aggregation.  I understand
that your approach does not require the latter and we should be clear about
what forms of aggregation are necessary or desirable in the approaches
discussed.

- We need to be clearer about the approaches to QoSR vs. the use of RSVP.
Your approach requires it and some of the others discussed don't and this
affects the applicability of the approaches.

- There is some discussion about policy and how it relates to QoSR. (I tend
to believe that all QoSR really is a special form of policy but that's a
different discussion).  We need to make clear the distinctions between the
use of policy and how it affects protocols and approaches as well as the
policy boundaries that are created by AS's.

I propose that the authors work on these and other comments and try to
produce a new version of the draft in fairly short order.  We can have an
abbreviated last call thereafter.

	Eric

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 13 Jan 98 13:15:18 JST

Eric;

> reference your approach in sections 3.4 and 7 along with possible mention

Thank you very much.

> protocol boundaries.

Surely we have.

> Any QoSR work, including your approach, will require
> modification to routing protocols.

Agreed.

> We need to be specific that the
> routing protocols and moving to interdomain protocols.

No, not necessarily.

> This is a pragmatic
> deployment.

Why, do you think, we can't start modifying BGP, until we finish
modifying OSPF and RIP?

The reality of the Internet and the reality of the IETF are
completely different.

We did develop OSPF and BGP simultaneously, because it is the way
to make OSPF and BGP interoperate very well.

Right?

> We will want to encourage common, or at least easily

That's why we need to modify (or consider to modify, at least)
inter/intra domain unicast/multicast routing protocols all at once.

> what forms of aggregation are necessary or desirable in the approaches

I can't disagree here, though I believe some of the aggregations
are unnecessary and/or harmful.

> affects the applicability of the approaches.

While PQC paper is written assuming RSVP, all PQC need is a collection
of real link state information along a reservation path (or tree, for
multicast).

If you think there will be some resource reservation protocol which
will not generate control packets over the data path, please show me
an example.

I will not be surprised if such a reservation protocol cannot
interoperate with any of the proposed QoSR protocols.

> policy boundaries that are created by AS's.

I believe that the policies of providers are distributed as policy
object which is a part of QoS (or ToS, if policy is highly static)
information distributed by QoSR.

I also congecture that the only meaningful policy will be the price,
becasue complex policy does not scale.

Still, some policy may also be able to stop distribution of some routing
information at some AS boudary. But, it is local policy. The policy may
be carried a few AS hops (assuming ASes are still needed). But carrying
such policy over the whole Internet will cause a scalability problem.
Moreover, use of a policy affects both best effort and QoS routing and
its use is not specific to QoSR.

Finally, if you want to consider generic policy issues further, you
have to think about yet another type of aggregation: "aggregation
of policy", which, I believe, is beyond the scope of QoSR. ;-)

							Masataka Ohta

---

From: "Eric S. Crawley" <[email-masked]>
Date: Tue, 13 Jan 1998 08:48:37 -0500

At 01:15 PM 1/13/98 JST, Masataka Ohta wrote:
[...]
Ohata-san,

Thanks for your agreement on most of the proposal I made.  I think we are
in a position to make forward progress.  I think there is only one item in
your response that I need to respond to.

>Why, do you think, we can't start modifying BGP, until we finish

I didn't say that we had to wait to modify interdomain protocols until we
were finished with modifying intradomain protocols.

>The reality of the Internet and the reality of the IETF are

I wouldn't say they are completely different but they are certainly
separate ;)

>to make OSPF and BGP interoperate very well.
While it is very possible to make changes in multiple routing protocols for
QoSR in parallel, that is beyond the scope of the QoSR WG.  With the
current charter of QoSR and the other routing protocol WGs, the schedule
for making any changes to routing protocols is the business of the
particular routing protocol WG.  Part of the reasoning for starting with
intradomain protocols is to gain further experience with QoSR methods in
environments where experiments are easier to test and deploy.  The work so
far has fallen into this pattern.  This ordering may not happen if someone
is bold enough to try experiments and make changes to BGP.  We can't
control that.

	Eric

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 14 Jan 98 22:33:34 JST

Eric;

> were finished with modifying intradomain protocols.

What did you say, then?

> particular routing protocol WG.

Then, why QoSR WG can say intra-domain should be tried first?

> Part of the reasoning for starting with
> environments where experiments are easier to test and deploy.

As I already stated, the easiest approach to test and deploy QoSR
is to use a protocol which does not distinguish inter/intra
domain.

Moreover, it's not a buisiness of QoSR WG to tell inter-domain
routing WGs delay QoSR deployment.

> The work so

Then, why you say inter-domain cases should be tried first?

						Masataka Ohta

---

From: "Eric S. Crawley" <[email-masked]>
Date: Thu, 15 Jan 1998 13:40:27 -0500

Ohta-san,

We seem to be going around in circles.  Let's try this again.  I believe we
all agree that in order to implement any approach to QoSR, including your
approach, 
changes are needed to routing protocols.  It would seem that since your
approach requires similar changes from any routing protocol it shouldn't
matter what order the protocols are changed. (Although, as you have noted,
your approach won't work very well over Distance Vector protocols). 

The working group has approached the problem of changes to routing
protocols from a broader perspective, looking at solutions that can work
for a variety of environments (i.e. with and without RSVP).  We believe it
is easier to start with intradomain routing protocols since some of the
scaling requirements might be more relaxed and they might be easier to test
in working networks.  This is the order that things have already been
happening.

We can't prevent, order, or otherwise dictate what other working groups do.
 We can only make suggestions based on what we have learned and out best
judgement.

>> were finished with modifying intradomain protocols.

I said that we want to *start* with the intradomain protocols, not wait
until all of them were finished before working on interdomain protocols!
This is not a completely serialized set of tasks.

>Then, why QoSR WG can say intra-domain should be tried first?

We can suggest it and we also observe that this is what has already
happened, witness the work on OSPF QoS routing solutions.

>is to use a protocol which does not distinguish inter/intra

While part of your approach does not distinguish between interdomain and
intradomain, it still requires changes to these protocols.  These changes
won't magically happen on their own and they won't happen in exact
parallel.  We can suggest that changes be made in intradomain protocols
first where they can be studied easier.

	Eric